Conformance: test @override checks on __init__ and __new__ - #2297
Merged
rchen152 merged 3 commits intoAug 8, 2026
Conversation
The @OverRide spec requires the overriding method to be assignable to the overridden one, with no exemption for __init__/__new__. Add cases to classes_override.py covering compatible overrides (no error), incompatible overrides decorated with @OverRide (error), and incompatible overrides without @OverRide (allowed). Score results: pyrefly conforms; mypy, pyright, pycroscope, ty, and zuban do not currently honor the check for constructors. Closes python#2222
|
All commit authors signed the Contributor License Agreement. |
srittau
added
the
topic: conformance tests
JelleZijlstra
approved these changes
Jun 23, 2026
jorenham
reviewed
Aug 7, 2026
jorenham
left a comment
jorenham
left a comment
Collaborator
There was a problem hiding this comment.
In typeshed the object.__init__ and object.__new__ are defined as (src)
class object:
# --snip--
def __init__(self) -> None: ...
def __new__(cls) -> Self: ...Every class without base implicitly inherits from object. So does that mean that e.g.
class A:
@override
def __init__(self, x: int) -> None: ...should now also be rejected? This technically indeed overrides object.__init__, but I'm not sure if reporting an error is actually useful in this case.
Member
|
I think it should, yes. It is not a particularly useful error, but the user did put that override decorator there, so the type checker should honor it. |
jorenham
approved these changes
Aug 7, 2026
Collaborator
|
Thanks @ashishpatel26! |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
5 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes #2222.
The
@overridesection of the spec states that a method decorated with@override"should [be treated] as a type error unless that method isoverriding a method or attribute in some ancestor class, and the type of the
overriding method is assignable to the type of the overridden method." There is
no exemption for
__init__/__new__, so although constructors are normallynot checked against their parents, an explicit
@overrideshould still triggerthe assignability check.
This adds cases to
tests/classes_override.py:ChildC1:@override__init__/__new__that are assignable to theparent — no error.
ChildC2:@override__init__/__new__with an incompatible parametertype — error (
# E[init],# E[new]).ChildC3: incompatible__init__/__new__without@override— allowed,to document the normal constructor exemption.
Scoring
Ran the conformance tool against the locked checker versions:
assignability check to
__init__/__new__even with@override→ scoredPartialwith a note.I marked the incompatible cases as mandatory errors (
# E) since the spec textis unconditional. If maintainers feel constructor override-checking should be
left optional, these could be relaxed to
# E?and the fivePartialscoresreturned to
Pass— happy to adjust.